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Abstract. We present Alias Refinement Types (Art), a new approach 
that uses predicate-abstraction to automate the verification of correct¬ 
ness properties of linked data structures. While there are many tech¬ 
niques for checking that a heap-manipulating program adheres to its 
specification, they often require that the programmer annotate the be¬ 
havior of each procedure, for example, in the form of loop invariants and 
pre- and post-conditions. We introduce a technique that lifts predicate 
abstraction to the heap by factoring the analysis of data structures into 
two orthogonal components: (1) Alias Types, which reason about the 
physical shape of heap structures, and (2) Refinement Types, which use 
simple predicates from an SMT decidable theory to capture the logical 
or semantic properties of the structures. We evaluate Art by implement¬ 
ing a tool that performs type inference for an imperative language, and 
empirically show, using a suite of data-structure benchmarks, that Art 
requires only 21% of the annotations needed by other state-of-the-art 
verification techniques. 


1 Introduction 

Separation logic (SL) [ 30 ] has proven invaluable as a unifying framework for 
specifying and verifying correctness properties of linked data structures. Para¬ 
doxically, the richness of the logic has led to a problem - analyses built upon it 
are exclusively either expressive or automatic. To automate verification, we must 
restrict the logic to decidable fragments, e.g. list-segments IHQ], and design cus¬ 
tom decision procedures U3llSISl26l27| or abstract interpretations [ 2213516 ] . Con¬ 
sequently, we lose expressiveness as the resulting analyses cannot be extended to 
rtser-defined structures. To express properties of user-defined structures, we must 
fall back upon arbitrary SL predicates. We sacrifice automation as we require 
programmer assistance to verify entailments over such predicates [219]. Even 
when entailment is automated by specializing proof search, the programmer has 
the onerous task of providing complex auxiliary inductive invariants 0231 . 

We observe that the primary obstacle towards obtaining expressiveness and 
automation is that in SL, machine state is represented by monolithic assertions 
that conflate reasoning about heap and data. While SL based tools commonly 
describe machine state as a conjunction of a pure, heap independent formula, 
and a * combination of heap predicates, the heap predicates themselves conflate 
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abs :: (int 

=> nat 1 

function abs(x){ 

x: int 

if (0 <= x) 

(0 ^ x); x :int 

return x; 

var r = 0 - x; 

r: {u = 0 — x}; 
—■(0 ^ x); x: int 

return r; 


> 



Fig. 1: Refinement types Fig. 2: Strongly updating a location 

reasoning about links ( e.g. reachability) and correctness properties ( e.g. sizes or 
data invariants), which complicates automatic checking and inference. 

In this paper, we introduce Alias Refinement Types (Art), a subset of separa¬ 
tion logic that reconciles expressiveness and automation by factoring the repre¬ 
sentation of machine state along two independent axes: a “ physical” component 
describing the basic shape and linkages between heap cells and a “logical” com¬ 
ponent describing semantic or relational properties of the data contained within 
them. We connect the two components in order to describe global logical prop¬ 
erties and relationships of heap structures, using heap binders that name pure 
“snapshots” of the mutable data stored on the heap at any given point. 

The separation between assertions about the heap’s structure and heap- 
oblivious assertions about pure values allow Art to automatically infer precise 
data invariants. First, the program is type-checked with respect to the physical 
type system. Next, we generate a system of subtyping constraints over the logical 
component of the type system. Because the logical component of each type is 
heap-oblivious, solving the system of constraints amounts to solving a system 
of Horn clauses. We use predicate abstraction to solve these constraints, thus 
yielding precise refinements that summarize unbounded collections of objects. 
In summary, this paper makes the following contributions: 

— a description of Art and formalization of a constraint generation algorithm 
for inferring precise invariants of linked data structures; 

— a novel soundness argument in which types are interpreted as assertions in 
separation logic, and thus typing derivations are interpreted as proofs; 

— an evaluation of a prototype implementation that demonstrates Art is ef¬ 
fective at verifying and, crucially, inferring data structure properties ranging 
from the sizes and sorted-ness of linked lists to the invariants defining binary 
search trees and red-black trees. Our experiments demonstrate that Art re¬ 
quires only 21% of the annotation required by other techniques to verify 
intermediate functions in these benchmarks. 


2 Overview 

Refinements Types and Templates. A basic refinement type is a basic type, 
e.g. int , refined with a formula from a decidable logic, e.g. nat = {w.int | 0 ^ z/} 
is a refinement type denoting the set of non-negative integers, where int is 
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the basic or physical part of the type and the refinement 0 ^ v is the log¬ 
ical part. A template is a refinement type where, instead of concrete formu¬ 
las we have variables n that denote the unknown to-be-inferred refinements. 
In the case that the refinement is simply true, we omit the refinement ( e.g. 
int ={v:int | true}). We specify the behaviors of functions using refined func¬ 
tion types: (x\ : ti ,..., x n : t n ) => t. The input refinement types U specify the 
function’s preconditions and t describes the postcondition. 

Verification. Art splits verification into two phases: (1) constraint generation , 
which traverses the program to create a set of Horn clause constraints over the 
k, and (2) constraint solving , which uses an off the shelf predicate abstraction 
based Horn clause solver m that computes a least fixpoint solution that yields 
refinement types that verify the program. Here, we focus on the novel step (1). 

Path Sensitive Environments. To generate constraints Art traverses the 
code, building up an environment of type bindings, mapping program variables 
to their refinement types (or templates, when the types are unknown.) At each 
call-site (resp. return), Art generates constraints that the arguments (resp. re¬ 
turn value) are a subtype of the input (resp. output) type. Consider abs in Fig.[j] 
which computes the absolute value of the integer input x. Art creates a tem¬ 
plate (int) => {v.int \ ki} where K\ denotes the unknown output refinement. 
(We write nat 1 in the figure to connect the inferred refinement with its n.) In 
Fig. a the environment after each statement is shown on the right side. The 
initial environment contains a binder for x, which assumes that x may be any 
int. In each branch of the if statement, the environment is extended with a 
guard predicate reflecting the condition under which the branch is executed. As 
the type {v.int \ v = x} is problematic if x is mutable, we use SSA renaming to 
ensure each variable is assigned (statically) at most once. 


Subtyping. The returns in the then and else yield subtyping constraints: 

x: int , 0 ^ x |— {v: int \ v = x} < {v: int \ n \} 
x -.int, ->(0 x), r : {v.int \ v = 0 — x} b {v:int \ v = r} < {v.int \ 


(1) 


which respectively reduce to the Horn implications 


(true aO<x) (v = x) => K\ 

(true a —>(0 ^ x) a r = 0 — x) =^> (v = r) =► 

By predicate abstraction m we find the solution = 0 =% v and hence infer 
that the returned value is a nat , i.e. non-negative. 

References and Heaps. In Fig. Q. absR takes a reference to a structure con¬ 
taining an int valued data field, and updates the data field to its absolute 
value. We use K 2 for the output refinement; hence the type of absR desugars 
to: (x : &x)/&x i—» (data : inf) =► ()/&x i—» (data : K 2 ) which states that absR 
requires a parameter x that is a reference to a location named &x. in an input 
heap where &x contains a structure with an inf-valued data field. The function 
returns () (i.e. no value) in an output heap where the location &x is updated to 
a structure with a K 2 -valued data-field. 
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Fig. 3: Strongly updating a collection. The fold and unfold annotations are automat¬ 
ically inserted by a pre-analysis (§ i) 

We extend the constraint generation to precisely track updates to locations. 
In Fig. 0, each statement of the code is followed by the environment r and heap 
£ that exists after the statement executes. Thus, at the start of the function, 
x refers to a location, Sex, whose data field is an arbitrary int. The call abs(d) 
returns a that is bound to t, which is then used to strongly update the data 
field of Sex from int to K\. At the return we generate a constraint that the return 
value and heap are sub-types of the function’s return type and heap. Here, we 
get the heap subtyping constraint: 

x:(&x), d :int, t:n\ \- &x >—> (data: v = t) < &x i—> <(data:/t2) 

which reduces by field subtyping to the implication: «i[t/V] => (y = t) => K2 
which (together with the previous constraints) can be solved to H2 = 0 < v 
letting us infer that absR updates the structure to make data non-negative. This 
is possible because the k variables denote pure formulas, as reasoning about 
the heap shape is handled by the alias type system. Next we see how this idea 
extends to infer strong updates to collections of linked data structures. 

Linked Lists. Linked lists can be described as iso-recursive alias types [37j. The 
definition 

type Zist[A] = >-* t: li st[ A], h: (data.: A, next:? (if) 

says Zisi[A] is a head structure with a data field of type A, and a next field 
that is either null or a reference to the tail, denoted by the ?(£) type. The heap 
t i-» t:list\A] denotes that a singleton ZjsZ[A] is stored at the location denoted 
by t if it is reachable at runtime. The 3! quantification means that the tail is 
distinct from every other location, ensuring that the list is inductively defined. 

Consider absL from Fig. which updates each data field of a list with its 
absolute value. As before, we start by creating a « 3 for the unknown output 
refinement, so the function gets the template 

(x:(&x))/&:r >—> Xq :list\int ] =► ()/&x 1—> x r ■ list[n 3] 

Fig. a shows the resulting environment and heap after each statement. 
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The annotations unfold and fold allow Art to manage updates to collections 
such as lists. In Art, the user does not write fold and unfold annotations; these 
may be inferred by a straightforward analysis of the program(§ M ). 

Unfold. The location &x that the variable x refers to initially contains a list[int] 
named with a heap binder Xo . The binder Xq may be used in refinements. Suppose 
that x is a reference to a location containing a value of type list[A]. We require 
that before the fields of x can be accessed, the list must be unfolded into a head 
cell and a tail list. This is formalized with an unfold(ftx) operation that unfolds 
the list at &x from &x >—> Xq :list[int\ to 

&x i—► X \: (data:inf, next: ?(&f)) * &f i—» t 0 : list\int ], 

corresponding to materializing in shape analysis. The type system guarantees 
that the head structure and (if next is not null) the newly unfolded tail structure 
are unique and distinct. So, after unfolding, the structure at &x can be strongly 
updated as in absR. Hence, the field assignment generates a fresh binder X2 for 
the updated structure whose data field is a K\, the output of abs. 

Fold. After updating the data field of the head, the function tests whether the 
next field assigned to xn is null, and if so returns. Since the expected output is 
a list, Art requires that we fold the structure back into a - effectively 

computing a summary of the structure rooted at &x. As xn is null and xn : 
jy:?(&t) | v = £2.next}, fold(&x) converts &x 1— > X2 : (data: Ki, next :?(&£)) 
to &x 1—> listfn 3] after generating a heap subtyping constraint which forces the 
“head” structure to be a subtype of the folded list’s “head” structure. 

T3 |— &x 1—> X2 :(data:«i,...) < &x 1—> X2 : (data:K3,...) (2) 

If instead, xn is non-null, the function updates the tail by recursively invoking 
absL(xn). In this case, we can inductively assume the specification for absL and 
so in the heap after the recursive call, the tail location &t contains a list[n 3]. 
As xn and hence the next field of X2 is non-null, the fold(&x) transforms 

&x i—> X2 :(data: Ki, next: ?(&f)) * 1—> t\ : list[i {3] 

into Ikx 1 —* fef[«3], as required at the return, by generating a heap subtyping 
constraints for the head and tail: 

T5 h &x >-> X2:(data:Ki,...) < &x <-* X2 :(data:K3,...) ( 3 ) 

T5 |- n► t\ : list[n3] < 1—> t\: list[n^\ ( 4 ) 

The constraints eq. i) , eq. i) and eq. 0) are simplified field-wise into the 
implications n\ => K3, k,\ ^ K3 and K3 K3 which, together with the previous 
constraints (eq. 0 )) solve to: K3 = 0 < iz. Plugging this back into the template 
for absL we see that we have automatically inferred that the function strongly 
updates the contents of the input list to make all the data fields non-negative. 

Art infers the update the type of the value stored at &x at fold and unfold 
locations because reasoning about the shape of the updated list is delegated to 
the alias type system. Prior work in refinement type inference for imperative 
programs [321 can not type check this simple example as the physical type sys¬ 
tem is not expressive enough. Increasing the expressiveness of the physical type 
system allows Art to “lift” invariant inference to collections of objects. 
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Fig. 4: Inserting into a collection 

Snapshots. So far, our strategy is to factor reasoning about pointers and the 
heap into a “physical” alias type system, and functional properties ( e.g. values 
of the data held) into quantifier- and heap-free “logical” refinements that may be 
inferred by classical predicate abstraction. However, reasoning about recursively 
defined properties, such as the length of a list, depends on the interaction between 
the physical and logical systems. 

We solve this problem by associating recursively defined properties not di¬ 
rectly with mutable collections on the heap, but with immutable snapshot values 
that capture the contents of the collection at a particular point in time. These 
snapshots are related to the sequences of pure values that appear in the definition 
of predicates such as list in [ 30 ]. Consider the heap £ defined as: 

& Xq i—♦ h:f data = 0,next = feaq) * &a:i i—> t:(data = l,next = null) 

We say that snapshot of Szxq in £ is the value Co defined as: 

Vo = (&X01 (data = 0,next = iq)) tq = (&aq,(data = l,next = null)) 

Now, the logical system can avoid reasoning about the heap reachable from 
Xq - which depends on the heap - and can instead reason about the length of 
the snapshot vo which is independent of the heap. 

Heap Binders. We use heap binders to name snapshots in the refinement logic. 
In the desugared signature for absR from Fig. 0 , 

(x:/&ex >-* xq :list\int\ => ()/&ex>-* x r :list[nat] 

the name Xq refers to the snapshot of input heap at Szx. In Art, no reachable 
cell of a folded recursive structure (e.g. the list rooted at kx) can be modified 






7 


without first unfolding the data structure starting at the root: references pointing 
into the cells of a folded structure may not be dereferenced. Thus we can soundly 
update heap binders locally without updating transitively reachable cells. 
Measures. We formalize structural properties like the length of a list or the 
height of a tree and so on, with a class of recursive functions called measures , 
which are catamorphisms over (snapshot values of) the recursive type. For ex¬ 
ample, we specify the length of a list with the measure: 

len :: list[A] => int len(null) = 0 len(x) = 1 + len (x.next) 

We must reason algorithmically about these recursively defined functions. The 
direct approach of encoding measures as background axioms is problematic due 
to the well known limitations and brittleness of quantifier instantiation heuris¬ 
tics [ 12 ]. Instead, we encode measures as uninterpreted functions, obeying the 
congruence axiom, Vx, j/.x = y => f{x) = f(y). Second, we recover the seman¬ 
tics of the function by adding instantiation constraints describing the measure’s 
semantics. We add the instantiation constraints at fold and unfold operations, 
automating the reasoning about measures while retaining completeness ( 35 ) . 

Consider insert in Fig.U, which adds a key k of type A into its position in an 
(ordered) list\A\, by traversing the list, and mutating its links to accomodate 
the new structure containing k. We generate a fresh k4 for the output type to 
obtain the function template: 

(A, x: ?(&x))/&x 1—> xq : list[A] => (&?)/&Z >-*• {v. list\A] \ K4} 

Here, the snapshot of the input list x upon entry is named with the heap binder 
xq; the output list must satisfy the (as yet unknown) refinement K4. 

Constraint generation proceeds by additionally instantiating measures at 
each fold and unfold. When x is null, the fold(&y) transforms the binding 
&y 1—* 2/0 : (data: A, next mull) into a (singleton) list >—> yi:list[A\ and 
so we add the instantiation constraint len(yi) = 1 to the environment. Hence, 
the subsequent return yields a subtyping constraint over the output list that 
simplifies to the implication: 

len(xo) = 0 a len(yi) = 1 => v = yi =^> K4 ( 5 ) 

When x is non-null, unfold (&x) transforms the binding &x xo :list[A] to 
&x 1—> X\ : (data: a, next: ?(&t)) * Set >—► to: list[A] 

yielding the instantiation constraint len(xo) = 1 + len (to) that relates the length 
of the list’s snapshot with that of its tail’s. When k <= x.data the subsequent 
folds create the binders £2 and 2/3 with instantiation constraints relating their 
sizes. Thus, at the return we get the implication: 

len(xo) = l + len(fo) a len(x 2 ) = l + len(f 0 ) a len(y 3 ) = l + len(x 2 ) => v = y 3 => K4 

( 6 ) 

Finally, in the else branch, after the recursive call to insert, and subsequent 
fold, we get the subtyping implication 

len(xo) = l + len(fo) A^fy Xq/uqAq] Alen(x 2 ) = l-flen(uo) v = x 2 => K4 ( 7 ) 
The recursive call that returns uq constrains it to satisfy the unknown refinement 
K4 (after substituting to for the input binder xq). Since the heap is factored out by 



Fig. 5 : Insertion Sort 

the type system, the classical predicate abstraction fixpoint computation solves 
eqs. 0) to ( 0 ) to K4 = len(i/) = 1 + len(a;o) inferring a signature that states that 
insert’s output has size one more than the input. 

Abstract Refinements. Many important invariants of linked structures require 
us to reason about relationships between elements of the structure. Next, we show 
how our implementation of Art allows us to use abstract refinements, developed 
in the purely functional setting [ 5 ' 6 j . to verify relationships between elements of 
linked data structures, allowing us to prove that insertSort in Fig. [B| returns an 
ordered list. To this end, we parameterize types with abstract refinements that 
describe relationships between elements of the structure. For example, 
type list[A](jf) = 3 U >—> t: list\\v. A | p(data, r/)}](p)./i:(data: A, next: ?(/)) 
is the list type as before, but now parameterized by an abstract refinement p 
which is effectively a relation between two A values. The type definition states 
that, if the data fields have values x±,... ,x n where Xi is the i th element of the 
list, then for each i < j we have p{xi, Xj). 

Ordered Lists. We instantiate the refinement parameters with concrete refine¬ 
ments to obtain invariants about linked data structures. For example, increasing 
lists are described by the type incList[A ] = Zisi[A]((<)). 

Verification. Properties like sortedness may be automatically infered by using 
liquid typing m- Art infers the types: 

insertSort :: (?list[A]) =► incList\A ] insert :: (A, ?incList\A]) =► incList[A ] 
i.e. that insert and insertSort return sorted lists. Thus, alias refinement types, 
measures, and abstract refinements enable both the specification and automated 
verification of functional correctness invariants of linked data structures. 

3 Type Inference 

To explain how Art infers refinement types as outlined in § 0 , we first explain 
the core features of Art’s refinement type system. We focus on the more novel 
features of our type system; a full treatment may be found in Fig. [13 • 

3.1 Type Rules 

Type Environments. We describe Art in terms of an imperative language 
Imp with record types and with the usual call by value semantics, whose syntax 
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Expressions e ::= n | true | false | null | re x \ e®e 
Statements s ::= s; s \ x = e | y = x.f \ x.f — e \ if e then s else s 
| return e | x = alloc {/ : e} | a; = /(e) 
unfold(t) | fold(£) | concr(x) | pad(t) 
Programs p ::= function f(x) {s} 


Primitive Types 

b : 

= int | 

bool | a | null | 

<£> | ?(£) 

Types 

T 

= b | C[T] | </:T> 


Refined Types 

T 

= {u:t 

1 P} 


Type Definition 

C 

:= C[a] 

= 3 !T.x:</:T> 


Contexts 

r 

:= 0 1 

x:T; r | e; P 


Heaps 

£ 

:= emp 

£ x:C\T] 

£*£>—> 

Function Types 

S 

= V£, a 

(F?T)/£ 

x':T'/£' 


n e Integers, re e Reference Constants, x,y,fe Identifiers, ® e {+, 

Fig. 6: Syntax of Imp programs and types 

is given in Fig. 0. A function environment is defined as a mapping, from 
functions / to function schemas S. A type environment (A) is a sequence of type 
bindings x:T and guard expressions e. A heap (A) is a finite, partial map from 
locations {(.) to type bindings. We write r(x) to refer to T where x:T e A, and 
£(£) to refer to x:T where the mapping t i—> x:T e £. 

Type Judgements. The type system of Art defines a judgement <f> (- / :: S, 
which says given the environment ( f> 1 the function / behaves according to its 
pre- and post-conditions as defined by S. An auxiliary judgement T, £ \— s :: 
r'/ £' says that, given the input environments r and A, s produces the output 
environments r' and £' . We say that a program p typechecks with respect to 
if, for every function / defined in p, <3> I— / :: 

Well-Formedness. We require that types T be well formed in their local envi¬ 
ronments r and heaps £ , written r, £ I— T. A heap £ must heap be well formed 
in its local environment r, written r \- £. The rules for the judgment (§ 0) 
capture the intuition that a type may only refer to binders in its environment. 
Subtyping. We require a notion of subsumption, e.g. so that the integer 2 
can be typed either as {v : int j v = 2} or simply int. The subtyping relation 
depends on the environment. For example, {v : int \ v = x} is a subtype of 
{v.int | v = 2} if x:{v:int \ v = 2} holds as well. Subtyping is formalized by the 
judgment F \- T) < T 2 , of which selected rules are shown in Fig. [llj. Subtyping 
in Imp reduces to the validity of logical implications between refinement predi¬ 
cates. As the refinements are drawn from a decidable logic of Equality, Linear 
Arithmetic, and Uninterpreted Functions, validity can be automatically checked 
by SMT solvers [T2j- The last two rules convert between non-null and possibly 
null references {(€) and ?(£>)• 

Heap Subtyping. The heap subtyping judgment r |— £ < £' describes when 
one heap is subsumed by another. Fig. |ll| summarizes the rules for heap sub¬ 
sumption. Heap subtyping is covarianf which is sound because our type system 
is flow sensitive - types in the heap are updated after executing a statement. 
Statements. When the condition x, y fresh appears in the antecedent of a rule, 
it means that x and y are distinct names that do not appear in the input en- 
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Subtyping 


F I- Ti < t 2 , f b S < S' 
Vahdgr 1 =» Ip] => Ip']) ^ b 

r b {f.b | p} < {u:b | p'} 

Valid (l r ] => [p] =*• Ip' a v b null!) 

-;- <-DOWN 

r b \vVl{€) | p} < {v:(£) | p } 


Valid(iri =» |[p] =» Ip']) < upl Vaiidgr} =» [p| =» Up'I) 

r |- {w.(£) I p} < {u:?(£) I p'} F b {p:null | p} < {v’■'!(£) | p'} 


J 1 I— emp < emp 
Heap Folding 


<-EMP 


r b s < s' r \-t <t' 

r (- S *£^> x:T < S' *£^ x:T' 


<-IIEAP 


F \— x: Ti/Si > x: T 2 /S 2 


locs{T\) n Dom(Si) = 0 S b 7i < T 2 
F \— x:Ti/Si > x\T 2 /S2 


F-base 


Si = S’i * £ >—> x :T S 2 — S 2 * £ >—> x:T' 

F |- {v:(€) | p} < T 2 FVx-.T/S'i\>x-.T'/S' 2 

- r-REF 

F b y:{v:(i) | p}/Si > p:T 2 /S 2 

Fb{^:?<^>|p}<T2 
Si = Sj * £ 1 —» y :T S 2 = S 2 * £ 1 —* y.T' 
x : {v:?(£) | p a v b null}', F b y:T/S[ > y:T'/S 2 
x\ {v■.?(€) \p a v = null}; F h y:T/S[ t> y.T 1 /S 2 ^ 

r b x:{^:?<£) | p}/Si > *:T 2 /S 2 

lb^: Ti/Si t> X'.Fij S 2 _ 

- == - -- F-i-ieap 

/'b?/: \fi : / ;>/S, > ;/: </,: '/'/>/>; 2 


Fig. 7: Selected subtyping, heap subtyping, and heap folding rules 






Statement Typing 


< 5 ,X,X b s :: F'/E' 
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r b x : (£) £ >-> z : (fj : T)) £ X 

$,r,E\-y = x.fi :: y:Ti-,r/E 


r \- x : (£) F \- e \ {v -,t \ p} 

T r = NameFields{z, (fo .To, ..., fi: {v\t \ v = e},...)) 2 /res/i 

(fj : Tj ) * X b x.fi = e :: T/£ z:T r * E 


for each e/, X, X b e/ : 7/ T = NameFields(z,(f :T)) £, z fresh 

<P, r, E \— x = alloc {/ : e/} :: * :<£>; r/£ >—> z:T * E 


r,E \- x : (€) T y = {u:t \ p} T z = {u:t \ u — y} z fresh 
<P, r,£ >-* y:T y * E \- concr(a;) v. y.T y \F /£ z~.T z * E 


T-concr 


r b Cfn] = 3 ! Xc'.Tc C[a\ b m m(a :) = e m 
X 1 — £ 1—> x: {v \C[T] | (/}* Xo E' = £ < —> a; c : [T/a]T c * [T/a]X c =1= Xo 
F, E \-T r, E' b E' Dom(E c ), Binders(E c ), x c fresh 
4 ?,F,E b unf old(^) :: (/\ m(a:) = e m ); X/X' 


T-UNFOLD 


X b C\oi\ = 3! X c . x:T c 

F h x-.T x /E x t>x:[T/a]T c /[T/a]E c £b t^y.T y *E' F b X < X' 
X[a] bM m(x) = e m = {^:X[T] | /\ m m(t/) = e m } y fresh 
<£>, F, £ 1 —> x : T x * E x tXb f old(£) :: X /£ 1—> y:T y * E' 


Fig. 8: Selected Statement Typing Rules. We assume that type definitions (and, hence, 
measures over these definitions) X b X[q] = 3! X. x:T are a-convertible. 

vironment X or heap X. We write \y/x\ for the capture avoiding substitution 
that maps x to y. The rules for sequencing, assignment, control-flow joins, and 
function calls are relatively straightforward extensions from previous work ( e.g. 
[32]). The complete set of rules may be found in Fig. M- 

Allocation. In T-ALLOC, a record is constructed from a sequence of field name 
and expression bindings. The rule types each expression e/ as Tf, generates a 
record type T, and allocates a fresh location t on the heap whose type is T. To 
connect fields with their containing records, we create a new binder y denoting 
the record, and use the helper NameFields{ Fig. to strengthen the type of 

each field-binding for y from f-.{vf.T \ p}, to f\{vf.T |p a Vf = Field (r^, /)}. 
Here, Field is an uninterpreted function. 

Access. T-RD and T-WR both require that non -null pointers are used to access 
a field in a record stored on the heap. As T-ALLOC strengthens each type with 
NameFields, the type for y in T-rd contains the predicate Vf i = Field(i/,/i)- 
Any facts established for y are linked, in the refinement logic, with the original 
record’s field: when a record field is mutated , a new type binding is created in 
the heap, and each unmutated field is linked to the old record using Field. 
Concretization. As heaps also contain bindings of names to types, it would 
be tempting to add these bindings to the local environment to strengthen the 
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subtyping context. However, due to the presence of possibly null references, 
adding these bindings would be unsound. Consider the program fragment: 

function f(){ return null; } 

function g(){ var p = f(); assert( false ) } 

One possible type for f is ()/emp => 3\£. r:l(t//£ >-> x:{v:int \ false} because 
the location £ is unreachable. If we added the binding x\{v:int \ false} to F 
after the call to f, then the assert (false) in g would unsoundly typecheck! 

We thus require that in order to include a heap binder in a local context, 
F, the location must first be made concrete , by checking that a reference to it 
is definitely not null. Concretization of a location £ is achieved with the heap 
annotation concr(a:). Given a non-null reference, T-CONCR transforms the local 
context F and the heap £ by (1) adding the binding y.T y at the location £ to 
F ; (2) adding a fresh binding z:T z at i that expresses the equality y = z. 
Unfold. T-UNFOLD describes how a type constructor application C[a] may be 
unfolded according to its definition. The context is modified to contain the new 
heap locations corresponding to those mentioned in the type’s definition. The 
rule assumes an a-renaming such that the locations and binders appearing in 
the definition of C are /res/i, and then instantiates the formal type variables a 
with the actual T. The environment is strengthened using the thus-instantiated 
measure bodies. 

Fold. Folding a set of heap bindings into a data structure is performed by T- 
fold. Intuitively, to fold a heap into a type application of C, we ensure that it 
is consistent with the definition of C. Note that the rules assume an appropriate 
a-renaming of the definition of C. Simply requiring that the heap-to-be-folded 
be a subtype of the definition’s heap is too restrictive. Consider the first fold in 
absL in Fig. 0- As we have reached the end of the list xn = null we need to fold 

&x x\ : (data :nat, next to'list[int\ 

into &x i—> X 2 ■ list[nat ]. An application of heap subtyping, i.e. requiring that the 
heap-to-be-folded is a subtype of the body of the type definition, would require 
that Szt i—> list\int\ < Szt >—> list\nat ], which does not hold! However, the fold is 
safe, as the next field is null, rendering Szt unreachable. We observe that it is 
safe to fold a heap into another heap, so long as the sub-heap of the former that 
is reachable from a given type is subsumed by the latter heap. 

Our intuition is formalized by the relation F, £ |— x:Ti/£ i\>x:T 2 /£ 2 , which 
is read: “given a local context F, £, the type Tj and the heap £\ may be folded 
into the type T 2 and heap £ 2 .” F-BASE defines the ordinary case: from the point 
of view of a type T, any heap £\ may be folded into another heap £ 2 . On the 
other hand, if T\ is a reference to a location £, then F-REF additionally requires 
the folding relation to hold at the type bound at £ in £\. 

F-?REF splits into two cases, depending on whether the reference is null 
or not. The relation is checked in two strengthened environments, respectively 
assuming the reference is in fact null and non-null. This strengthening allows 
the subtyping judgement to make use reachability. Recall the first fold in absL 
that happens when xn = null. To check the fold(ftx), the rule requires that the 
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CGen : FunEnv x TypeEnv x HeapEnv x Stmt —> {Constr} x TypeEnv x HeapEnv 
CGen(^,/ 1 ,X',s) = match s with 

| y = x.f —> let £ = loc(r(x)) in ({F h F(x) < <£>}, y:TypeAt(r,£);/",£■) 

| x.f = e — * let (cs, t) = CGE x(r,S,e) 

£ = Loc(t) 

(y:T y , z) = (E{£), Freshld()) 

ht = NameFields(z, T y [f : Shape(t) n (v = e)]) 

in (cs u {F ht< (£)}, r, E\£ h-> z:ht]) 


Fig. 9: Statement constraint generation 

problematic heap subtyping F |— i— > list\int\ < &t >—* list[nat ] only holds 

when x.next is non-null, i.e. when r is 

xn \{v.l(fzf) | v = X 2 .next}, xn = null, £ 2 -next ^ null 

This heap subtyping reduces to checking the validity of the following, which 
holds as the antecedent is inconsistent: 

xn = X 2 .next a xn = null a a^.next ^ null => 0 v. 

3.2 Refinement Inference 

In the definition of the type system we assumed that type refinements were given. 
In order to infer the refinements, we replace each refinement in a program with 
a unique variable, K i , that denotes the unknown refinement. More formally, let 
<P denote a function environment as before except each type appearing in <P 
is optionally of the form {v:t \ Ki}, i.e. its refinement has been omitted and 
replaced with a unique k variable. Given a set of function definitions p and 
a corresponding environment of unrefined function signatures to infer the 
refinements denoted by each k we extract a system of Horn clause constraints C. 
The constraints, C, are satisfiable if there exists a mapping of K of n -variables to 
refinement formulas such each implication in KC , i.e. substituting each Ki with 
its image in K , is valid. We solve the constraints by abstract interpretation in the 
predicate abstraction domain generated from user-supplied predicate templates. 
For more details, we refer the reader to m ■ We thus infer the refinements missing 
from <1> by finding such a solution, if it exists. 

Constraint Generation. Constraint generation is carried out by the proce¬ 
dure CGen which takes a function environment type environment (T), heap 
environment (IF), and statement (s) as input, and ouputs (1) a set of Horn con¬ 
straints over refinement variables k that appear in d>, T, and F; (2) a new type- 
and heap-environment which correspond to the effect (or post-condition) after 
running s from the input type and heap environment (pre-condition). 

The constraints output by CGen correspond to the well-formedness con¬ 
straints, r, S \- T, and subtyping constraints, r I— T < T' . defined by the 
type system. Base subtyping constraints T I— {v.b \ p} < {v:b \ q} correspond 
to the (Horn) Constraint [T] =^> p q, where JT] is the conjunction of all of 
the refinements appearing in T [31]. Heap Subtyping constraints T I— E < S' are 
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decomposed via classical subtyping rules into base subtyping constraints between 
the types stored at the corresponding locations in £ and £'. This step crucially 
allows the predicate abstraction to sidestep reasoning about reachability and the 
heap, enabling inference. 

CGen proceeds by pattern matching on the statement to be typed. Each 
FreshTypeO or Fresh () call generates a new k variable which may then appear 
in subtyping constraints as described previously. Thus, in a nutshell, CGen cre¬ 
ates Fresh templates for unknown refinements, and then performs a type-based 
symbolic execution to generate constraints over the templates, which are solved 
to infer precise refinements summarizing functions and linked structures. As an 
example, the cases of CGen corresponding to T-rd and T-wr are show in Fig.0. 

3.3 Soundness 

The constraints output by CGen enjoy the following property. Let (C,r' ,£') be 
the output of CGen(^,T, A,s). If C is satisfiable, then there exists some solution 
K such that K&, KT, K£ \- s :: KT'/KE' [31], that is, there is a type derivation 
using the refinements from K. Thus I\ yields the inferred program typing <1 = 
K^> 1 where each unknown refinement has been replaced with its solution, such 
that <£ |— / <?>(/) for each / defined in the program p. 

To prove the soundness of the type system, we translate types, environments 
and heaps into separation logic assertions and hence, typin g d erivations into 
proofs by using the interpretation function [•]. We prove (§ §[CJ) the following: 


Theorem 1. [Typing Translation] 

. If $,r,£\-s::r'/£' then [*] b {[T, £}} s {[ r, S' ]} 

• If $ b / :: S then [$] b {Pre(S)} Body{f) {Post(S)} 

Pre(S ), Post(S) and Body(f) are the translations of the input and output types 
of the function, the function (body) statement. As a corollary of this theorem, 
our main soundness result follows: 

Corollary 1. [Soundness] If 0, emp h s :: T/£, then [<£] b {true} s {true} 

If we typecheck a program in the empty environment, we get a valid separation 
logic proof of the program starting with the pre-condition true. We can encode 
programmer-specified asserts as calls to a special function whose type encodes 
the assertion. Thus, the soundness result says that if a program typechecks then 
on all executions of the program, starting from any input state: (1) all memory 
accesses occur on non -null pointers, and (2) all assertions succeed. 

4 Experiments 

We have implemented alias refinement types in a tool called Art. The user pro¬ 
vides (unrefined) function signatures, and Art infers (1) annotations required 
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Data Structure 

Properties 

Procedures 

LOC 

T 

Singly linked list 

Len, Keys 

append, copy, del, find, insBack, 
insFront, rev 

73 

2 

Doubly linked list 

Len, Keys 

append, del, delMid, insBack, 
insMid,insFront 

90 

16 

Cyclic linked list 

Len, Keys 

delBack, delFront,insBack, 
insFront 

49 

2 

Sorted linked list 

Len, Keys, Sort 

rev, double, pairwiseSum, 
insSort, mergeSort, quicksort 

135 

10 

Binary Tree 

Order, Keys 

preOrder, postOrder, inOrder 

31 

2 

Max heap 

Heap, Keys 

heapify 

48 

27 

Binary search tree 

BST, Keys 

ins, find, del 

105 

11 

Red-black tree 

Red-black, BST, Keys 

ins, del 

322 213 


Table 1: Experimental Results (Expressiveness) 


for alias typing, and (2) refinements that capture correctness invariants. We eval¬ 
uate Art on two dimensions: the first demonstrates that it is expressive enough 
to verify a variety of sophisticated properties for linked structures; the second 
that it provides a significant automation over the state-of-the-art, represented 
by the SMT-based VCDryad system. VCDryad has annotations comparable 
to other recent tools that use specialized decision procedures to discharge Sepa¬ 
ration Logic VCs M- Ou r benchmarks are available at [I]. 

Expressiveness. Table |T] summarizes the set of data structures, procedures, 
and properties we used to evaluate the expressiveness of Art. The user provides 
the type definitions, functions (with unrefined type signatures), and refined type 
specifications to be verified for top-level functions, e.g. the top-level specification 
for insertSort. LOC is lines of code and T, the verification time in seconds. 

We verified the following properties, where applicable: [Len] the output data 
structures have the expected length; [Keys] the elements, or “keys” stored in each 
data structure [Sort] the elements are in sorted order [Order] the ouput elements 
have been labeled in the correct order {e.g. preorder) [Heap] the elements sat¬ 
isfy the max heap property [BST] the structure satisfies the binary search tree 
property [Red-black] the structure satisfies the red-black tree property. 

Automation. To demonstrate the effectiveness of inference , we selected bench¬ 
marks from Table [l| that made use of loops and intermediate functions requiring 
extra proof annotations in the form of pre- and post-conditions in VCDryad, 
and then used type inference to infer the intermediatepre- and post-conditions. 
The results of these experiments is shown in Table [2|. We omit incomparable 
benchmarks, and those where the implementations consist of a single top-level 
function. We compare the number of tokens required to specify type refinements 
(in the case of Art) and pre- and post-conditions (for VCDryad). The table 
distinguishes between two types of annotations: (1) those required to specify 
the desired behavior of the top-level procedure, and (2) additional annotations 
required (such as intermediate function specifications). Our results suggest that 
it is possible to verify the correctness of a variety of data-structure manipulating 
algorithms without requiring many annotations beyond the top-level specifica- 
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Data Structure Procedure 

Specificat 

ART VCDryad 

ion Annotation Specification Annotation 

Singly Linked List (definition) 

34 

- 

31 

- 

rev 

5 

0 

11 

15 

Sorted Linked List (definition) 

38 

- 

50 

- 

rev 

11 

9 

17 

15 

double 

0 

4 

7 

54 

pairwiseSum 

0 

4 

13 

75 

insSort 

5 

0 

20 

17 

mergeSort 

5 

18 

18 

79 

quicksort 

5 

18 

11 

140 

Binary Search Tree (definition) 

58 

- 

55 

- 

del 

7 

32 

20 

33 

Total 

168 

63 

253 

428 


Table 2 : Experimental results (Inference). For each procedure listed we compare the 
number of tokens used to specify: ART Type refinements for the top-level procedure in 
Art; ART Annot manually-provided predicate templates required to infer the neces¬ 
sary types ED; VCDryad Spec pre- and post-conditions of the corresponding top-level 
VCDryad procedure; and VCDryad Annot loop invariants as well as the specifications 
required for intermediate functions in VCDryad. Art Annot totals include only unique 
predicate templates across benchmarks. 


tion. On the benchmarks we examined, overall annotations required by Art were 
about 34% of those required by VCDryad. Focusing on intermediate function 
specification, Art required about 21% of the annotation required by VCDryad. 

Limitations. Intuitively, Art is limited to “tree-like” ownership structures: 
while sharing and cycles are allowed (as in double- or cyclic-lists), there is a 
tree-like backbone used for traversal. For example, even with a singly linked list, 
our system will reject programs that traverse deep into the list, and return a 
pointer to a cell unboundedly deep inside the list. We believe it is possible to 
exploit the connection made between the SL notion of “magic wands” and the 
type-theoretic notion of “zippers” m identified in [33] to enrich the alias typing 
discipline to accommodate such access patterns. 

5 Related Work 

Physical Type Systems. Art infers logical invariants in part by leveraging 
the technique of alias typing [37121 . in which access to dynamically-allocated 
memory is factored into references and capabilities. In [7128] . capabilities are 
used to decouple references from regions, which are collections of values. In 
these systems, algebraic data types with an ML-like “match” are used to discover 
spatial properties, rather than null pointer tests, fold & unfold are directly 
related to roll & unroll in m- These operations, which give the program access 
to quantified heap locations, resemble reasoning about capabilities [34128] . These 
systems are primarily restricted to verifying (non-)aliasing properties and finite, 
non-relational facts about heap cells (i.e. “typestates”), instead of functional 












17 


correctness invariants. A possible avenue of future work would be to use a more 
sophisticated physical type system to express more data structures with sharing. 

Logical Type Systems. Refinement types |38|24|19] , encode invariants about 
recursive algebraic data types using indices or refinements. These approaches 
are limited to purely functional languages, and hence cannot verify properties 
of linked, mutable structures. Art brings logical types to the imperative setting 
by using m to structure and reason about the interaction with the heap. 

Interactive Program Logics. Several groups have built interactive verifiers 
and used them to verify data structure correctness mm- These verifiers require 
the programmer write pre- and postconditions and loop invariants in addition 
to top-level correctness specifications. The system generates verification condi¬ 
tions (VCs) which are proved with user interaction. )18j uses symbolic execution 
and SMT solvers together with user-supplied tactics and annotations to prove 
programs. describe separation logic frameworks for Coq and tactics that 

provide some automation. These are more expressive than Art but require non¬ 
trivial user assistance to prove VCs. 

Automatic Separation Logics. To automate the proofs of VCs ( i.e. entail- 
ment), one can design decision procedures for various fragments of SL, typically 
restricted to common structures like linked lists. [3] describes an entailment pro¬ 
cedure for linked lists, and PTT5|5| extend the logic to include constraints on list 
data. [20141261271 describe SMT-based entailment by reducing formulas (from a 
list-based fragment) to first-order logic, combining reasoning about shape with 
other SMT theories. The above approaches are not extensible (i.e. limited to list- 
segments); other verifiers support user defined, separation-logic predicates, with 
various heuristics for entailment [8[10j . Art is related to natural proofs |29l25j 
and the work of Heule et al. |16] , which instantiate recursive predicates using 
the local footprint of the heap accessed by a procedure, similar to how we insert 
fold and unfold heap annotations, enabling generalization and instantiation of 
structure properties. Finally, heap binders make it possible to use recursive func¬ 
tions (e.g. measures) over ADTs in the imperative setting. While our measure 
instantiation |19] requires the programmer adhere to a typing discipline, it does 
not require us to separately prove that the function enjoys special properties [35]. 

Inference. The above do not deal with the problem of inferring annotations 
like the inductive invariants (or pre- and post- conditions) needed to generate 
appropriately strong VCs. To address this problem, there are several abstract 
interpreters [2T tailored to particular data structures like list-segments [39] . 
lists-with-lengths [22]. Another approach is to combine separate domains for 
heap and data with widening strategies tailored to particular structures [BE]. 
These approaches conflate reasoning about the heap and data using monolithic 
assertions or abstract domains, sacrificing either automation or expressiveness. 
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A Imp with Annotations 

A.l Annotation Elaboration 

In § 0 we state that our soundness proof relies on a semantics-preserving elab¬ 
oration step that inserts assignments to ghost variables. More formally, we can 
take a typing derivation for a program in Imp as presented in § 0 and produce 
an elaborated source with an almost identical derivation. These elaborations 
amount to making assignments to ghost variables to correspond to locations and 
heap binders , and are thus semantics preserving because the ghost variables do 
not appear in the original program. The type judgements for the elaborated 
code are used in the soundness proof. The syntax of Imp with ghost variable an¬ 
notations is given in Fig. M Statement typing judgements with ghost variable 
annotations are given in Fig. 0 . 


Expressions e ::= n | true | false | null j re x | e®e 
Statements s ::= s; s \ x = e \ y = x.f \ x.f = z e | if e then s else s 
| return e | x = 2 allocr {/ : e} x = /(e) 
unfold(t,y) | fold(f,:r) | concr(a;,t/) | pad(^, x) 
Programs p ::= function f(x) {s} 

Primitive Types b ::= int. \ bool \ a | null | (£) \ ?(£) 

Types t ::= b \ C[T] \ </TT> 

Refined Types T ::= {v.t \ p} 

Type Definition C ::= C[a] = 3! E. x\(f : T') 

Contexts P ::= 0 | x:T;P e; P 

Heaps E ::= emp | E * £ i—» a; : C[T] | E * 1 1 -> x 

Function Types S ::= W,a. ( x\T)/E =s> 3\£'. x'-.T'/E' 


Fig. 10: Syntax of Imp programs and types 


B Well Formedness and Expression Typing 


Well-formedness rules are given in this section. Expression typing judgements 
are given in Fig. Il8 . 
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Subtyping 


X I- Ti < T 2 , X b X < E' 

Vaiidgr} =» Ip] =» [p']) ^ b 

X b {v.b I p} < {w.b I p'} 


x b x <t' 

Valid(l r ] =» |p| =» [p'D 
r b {v:C\T\ \p}<{v:C\T']\p'} 

r b T < T' vaiid([r]|=»[p]|=>[p , ]|) 
r b {^:< 7 TT> I p} < {v:(J 7 r') I p'} 

Valid ([X] =» [p] => |p' a v b null]) 

X b I p} < {!/:<£> I p'} 


<-APP 


<-REC 


<-DOWN 


VaM([x] =» [p] =» Ip']) < upl Vaiidgri =» |p| =» Ep'I) 

lb {^:<^)|p}< {u:?(£) I p'} X b {p:null | p} < | p'} 


X b emp < emp 
Heap Folding 


<-EMP 


x b x < x' x bT < t' 

rbXd«i:T<X' *£^x:T' 


<-HEAP 


F \— x: Ti/Xi > x: X2/X2 


locs(Ti ) n Dom(E 1) = 0 X b Xl < X2 
X b x:T1/X1 > x: X2/X2 


F-base 


Xi = XJ * l <—* x :T X2 = X2 * f 1—> x: T' 
r\- {v.{l)\p}<T 2 Xbx:T/Xi >x:T 7 Xi 

- r-REF 

X b p:{^:<^> | p}/Xi > p:T 2 /X 2 
X b {^: ?<^> | p} < X2 

Xi = Xj * £ 1 —* y.T X 2 = Xi * t —> y.T' 
x: {v ■.!(€) | p a ^ # null}', X b y.T/E i > y:T'/E 2 
x:{v:?(£) \p a v = null}; X b p:T/Xj > y.T'/E ' 2 p ?REp 
X b x:{^:?<£) | p}/Xi > x:X 2 /X 2 

X b x: Ti/Ei [> x: X 0 X2 

- = - = - F-heap 

X b p: </i: Ti)/Ei > p: </i: X/)/X 2 


Fig. 11: Subtyping, heap subtyping, and heap folding rules 
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Statement Typing 


<A A, A b s :: r'/E' 


F,E be: {v:t | p) 


T-assgn 


<F, F, E |- x = e :: x: {v.t \ v = e}\T /E 

<A A, A b Si :: r'/E' F', E' b s 2 :: r"/E" 
- T-seq 


$,r,s\- sv,s 2 ■■■■ r"/E" 

r |- E * £ 1 —> x: A £,x fresh 


T-pad 


A r, E b pad(«, x) :: r/E # £ >-* x:T 
r, E |— e : bool <F, e; A, E I— si :: -Ti; A/Ai A —'e; A, X 1 |— s 2 :: A 2 ; A / E 2 

r \- e' r i; r\- Ei<e' a 2; a b a 2 < a' 

for each x, e A n A 2 , Al; A, A |- xi : A A; A A 2 b x» : A 
Xi-.Ti-r,E I— Ai Xi :Tij r \ A 
$, A, E \- if e then si else s 2 :: Xi : A; A/A' 


T-if 


rhi:<<> Az:</i:A>EA 


T-rd 


A A, A b y = x.fi :: y: A; A/A 

f hi: (•£) Abe: {^:t | p} 

A r = NameFields(z,(fo : Ao,..., fi: {v.t \ v = e},.. .)>) 2 fresh 


A A, t m> y: (fj : Tf) * A I— x./i = z e :: T/£ z:T r * E 
for each e/, A, A b e/ : A/ A = NameFields(z,(f :A)) l, z fresh 


A A, A b x = 2 alloc« {/ : e/} :: x\(£)\ F/£ ^ z\T * E 

F, E \- x : (£) T y = {v.t \p] T z = {v.t \ v = y} z fresh 
A A, 1 1 — * y : T y * A |- concr(x, 2) :: y : T y \ F/l 1 — * 2 : A 2 * A 

A I- A[q] = 3! A c . x c :A c C[a] I -m m(x) = e m 


T-wr 


T-alloc 


T-concr 


A — £ 1 —> x:{v:C[T] \ q} * Ao E 1 = £ 1 —» * c : [A/a]A c * [A/q]A c * Ao 
A, A A A, A' h A' Dom(E c ), Binders(E c ), x c fresh 
A A, A b unf old(t, x c • Dom(E c ) ■ Binders(E c )) :: (/\ m(x) = e m ); A /A' 

m 

_A b C[a] = 3 ! Ac. x:A c 

F x:T x /E x i> x:[T/a]T c /[T/a]E c A b l >-► y :T y * A' A I- A < A' 
A[a] hii m(x) = e m A, = {^:C[T] | /\ m m(^) = e m } y fresh 


T-unfold 


A A, £ h-> x: Ac * Ax * A b f old(y, £) \: F/£ >-^ y :T y * E 1 
TZ = x-r -.Tn/En e A A e : [e/xR.]A-R A I— A < [c/xrJAr, 


T-fold 


Ai A * A ( h return e :: 0 


T-ret 


& \- f S A, A b (xj \ Tj)/Ei => Xo’.To/Eo = Inst(S,£, A) 
6* = [ej/x] (y:T y ,E' 0 ) = AddHeap(x 0 :A 0 ; A, A 0 ) 
for each j, A, A u * A m b : 0Aj A b A m < #Ai 
A A, A„ * A m b x = f(ej) :: x:9T 0 -,F/E u * 0A O 


T-CALL 


Fig. 12: Annotated Statement Typing Rules. In T-call, S is a-renamable. Note that 
the well-formedness check requires all output binders to be fresh in the calling context. 
We assume that type definitions (and, hence, measures over these definitions) A b 
C[q] = 3! A. x: A are a-convertible. 
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Well Formed Types | F, E \- T 

FV(p) c FV(z/:6;F) u FV(i7) p is well-sorted in v\b\F and E 


r,Eh{w.b\p} 

C[a] = 3! E. x:(f7T > F, E \- q 


WF-prim 


length(a) = length({^:&; | pt}) F, E b {v.bi \ pt} 


r,E\- {v-.C[{v:bi | pi}] | q} 


r,E\- {v.bi | Pi} F,E\-q fi = fv =» i = i' 
F,E h : </i ’{v'-bi | pi}> | <?} 


WF-app 


WF-rec 


Fig. 13: Well Formed Types 


Well Formed Type Definitions 

E I— T x : {v. (/: T) | p}, X 1 | — 23 
x ^ FV(X') TypeVars(X') u TypeVars({^:(/:T) | p}) c q 

hC[a] =3!r.x:{p:<7TT)|p] 


hC 


WF-def 


Fig. 14: Well Formed Type Definitions 


Well Formed Heaps and Worlds 


F\-E r,E\-E' r,E \- x:T/E' 


F, E \- T r,E\- E' 


F, E emp 


t £ Dom(E') x £ Binders!E') u Binders(F) 

WF-emp --- WF-bind 


F, E |— £ » x:T * E 1 




r h e 

x £ F x\T; r, E \- T 
x:T\F,E |— E’ 
r \-x:T/E' 


WF-heap 


WF-wld 


Fig. 15: Well Formed Heaps and Worlds 


Well Formed Schemas 


for each j, Xj £ F V(F) u FV(F) and Xj :Tj- F, Ei I— Tj 


Xj : Tj ; F, E I— Ei Xj : Tj : F (— x 0 • T 0 JE 0 x 0 $ FV(F) w FV(F) 
FV(F 0 ) $ FV(F) u FV(F) 


F,E\- S 


F, E |— VF, a. (xj :Tj)/Ei => 3!F>- x 0 -T 0 /E 0 


WF-fun 


Fig. 16: Well Formed Schemas 
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Well Formed Measures 


C\a\ I m m(x) = e 


csF* x. f :Tf .. .y e r f:T =» T' E F rh M e:T 

rhMC-.T* ry-M X.f : Tf r\-M f(e) : T' 


®:T x T'=> T" E T r \- M e : T F \- M e' : T' 
F \~m 6 © o! : T" 

F I—m e : bool F I—m e' : T F |—m e w : F 
F I—m if c then e / else e w : F 
h C[a] = 3! X. a;:F T v = SnapType(F, X) 
m : F„ =► F e F x:T v \-m e : T x: null |—m e : T 
C[q] hit m(x) = e 


Fig. 17: Well Formed Measures 


Expression Typing 


rXheiT 


X, X b n : {u : inf | ^ = n} 


T-INT 


| p} E F 


F,Xh null : {z/:null | v = null} 

F, X 1- ei : int F, X b e 2 : int 
F, X ei © e 2 : {v.int \ v — ei © e 2 } 
F,Xhe: {v.(t)\p} 


T,E \- x \ {v.r \ v = x} 
T-NULL 


T-OP 


F,X h e: {r :(€) | p a v b null} 

F, X b e : Ti F b Fi < F 2 F, X b F 2 


F, X I e : F 2 


T-ref-inv 

T-sub 


T-var 


Fig. 18: Expression Typing Rules 


Function Typing 




£ = dom(Ei) t 0 = dom(E 0 )\dom(£i) 
0,emp b S — Ml. Va. ( x:T)/£i => 3!£ 0 . x 0 'T 0 /E 0 
(F, X) = AddHeap(x: T, X;) 

1Z = Xo : T 0 /E 0 ] F, X I— s :: 0 
$h/::S 


Fig. 19: Function Typing Rules 
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Substitution of Heap Binders 


Subst(E, E 1 ) = 9E 1 where 9x 


x' £ >—> x : T G E and £ i— > x': T' £ E' 
x otherwise 


Fresh Renaming of Worlds 

FreshSubst(x:T/E) = FreshSubst’(a:, T, E, emp) 

FreshSubst'(a:, T, emp, 9) —\x'/x]-9 x fresh 

FreshSubst'(a:, T, £ >—> y-T y * E, E') = FreshSubst’(a;,T, E, [£'/£] ■ [y'/y] ■ 9) (I,y' fresh 


Strengthening Field Names 

NameFields({u:(f: {u f :r f | p/}> | p}) = {u:(f: {u f :r f \ p f a v f = field (v,f)}) \ p} 


Function Instantiation 

Instiyi. S,e -L,T) = Inst([£' /£]S, L, T) 

Inst(Va. S,e,T T) = Inst[[T/a]S, e, T) 

Inst(S, e,e) = S 

Local Context Strenghtening 

E = emp 

E = £ >-* y: {v :t \ p} * Eo, 
x : (£} £ F, and z fresh 
otherwise 


Add Heap (F, E) = \ 


[ (r,Z) 

(y.T-r',£^z-.{v.r \ v = y} * E') 


ir',E') 

where (F\ E') = AddHeap(F, E 0 ) 


Fig. 20: Helper Functions 
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C Soundness of ART 
D Soundness 

We translate types, environments and heaps into separation logic assertions and 
hence, typing derivations into separation logic proofs. We illustrate the transla¬ 
tion by example and present the key theorems; see § 0 for details. 

D.l Translation 

We define a translation [ • ] from types, contexts, and heaps to assertions in sep¬ 
aration logic. We translate a typing context T, £ by conjoining the translations 
of r and £. Next, we illustrate the translation of local contexts r and heaps £ 
using the insert function from Fig.0. When we describe e.g. afata program 
point, we are referring to the r before that program point’s execution. 

Local Contexts We translate contexts r into a conjunction of pure , i.e. heap 
independent, assertions. The context To before A contains two assumptions: (1) x 
is a possibly null reference to &x and (2) x is definitely null. Note that &x does 
not denote the application of a function called &; it is a distinct location named 
&x. We translate To by conjoining the translations of these contents. Note that 
translation states that if x is not null, then x refers to &x. 

To = x:?(&x), x = null [To] = (x A null =^> x = &x) a (x = null) 

Heaps We interpret heaps as (separated) conjunctions of impure (i.e., heap- 
dependent assertions) and pure assertions corresponding to the types of the 
values stored in each location. The heap before A states that if the location 
exists on the heap, then it refers a valid list, described by list(A, &x, x 0 ). 

£q = &x i —* xq : list\A] [170] = (&x A null) => list(A, &x, xq) (8) 

Type Predicates We translate the definition of the list[A] type into a sepa¬ 
ration logic assertion that characterizes the part of the heap where a list[A] is 
stored. For example, for the list type from Fig. 0 we define the type predicate 
as: 

list (A,t,x) = Snapshot^, x) a 3h,t,£ t . hd (A,£,h,£ t ) * ((£t # null) => list(A, £ t , t)) 
hd (A,l, h,£ t ) = \t >-> /i:(data : A, next :?<T t )>] 

Intuitively, the conjuncts of the assertion list(A, l, x ) say: (1) the snapshot x is a 
pure value comprising all the records (data and references) that are transitively 
reachable on the heap starting at t, and (2) the heap satisfies the “shape” invari¬ 
ants defined by the recursive alias type list[A ]. We prove that each well-formed 
type definition has a translation analagous to the above, allowing us translate 
heap-locations mapped to recursive types in a manner analagous to eq. (0). 

Records The other case is for heap-locations that are mapped to plain records. 

At B, insert has allocated a record to which y refers. There, we have 

Ti = T 0 ,y:&y (9) [A ] = [T 0 ] a (y ^ null =► y = hy) a (y A null) (10) 
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i.e. the binding for y is translated to the assertion for a maybe-null pointer 
plus the fact that y is not-null. The heap before executing B is translated: 

[Al] = [^ol * (&y 2/0 a 2/0 = (data:k, next:null)) (11) 

D.2 Soundness Theorem 

We prove soundness by showing that a valid typing of a statement s under given 
contexts can be translated into a valid separation logic proof of s under pre- 
and post-conditions obtained by translating the contexts. Note that there an 
(semantics-preserving) elaboration step that, for clarity, we defer to § 0 which 
inserts ghost variables to name locations and heap binders. 

Theorem 1. [Typing Translation] 

. If $,r,Z\-s::r’/E' then [*] b {[A S}} s {[A, £']} 

• // £ b / " S then [$] b {Pre(S)} Body(f) {Post{S)} 

Pre(S), Post(S) and Body(f) are the translations of the input and output 
types of the function, the function (body) statement. By virtue of how contexts 
are translated, the result of the translation is not a vacuous separation logic 
proof. As a corollary of this theorem, our main soundness result follows: 

Corollary 1. [Soundness] If <P, 0, emp b s :: T/E, then [[<£] b {true} s {true} 

If we typecheck a program in the empty environment, we get a valid separation 
logic proof of the program starting with the pre-condition true. We can encode 
programmer-specified asserts as calls to a special function whose type encodes 
the assertion. Thus, the soundness result says that if a program typechecks then 
on all executions of the program, starting from any input state: (1) all memory 
accesses occur on non-null pointers, and (2) all assertions succeed. 

The soundness proof proceeds by induction on the typing derivation. We show 
that the typing rules correspond to separation logic proofs using the appropriate 
proof rule. The critical parts of the proof are lemmas that translte the rules for 
subtyping and folding recursive type definitions into separation logic entailments: 

Lemma 1. [Folding] If T b x\T\fE\ t> x : T 2 /E 2 then 

[T] =*. [e~x:T 1 *S 1 ]=>lFV{E 2 ). [ £^x:T 2 *E 2 ] a 3y. Snapshot{£,y) 


Lemma 2. [Subtyping] 

• If r\-T 1 <T 2 then [P] => [D ] => [T 2 ] 

• If r bPi<r 2 then 

These lemmas effectively translate fold, unfold, and subtyping (Fig. El) into a 
combination of “skip” statements and the consequence rule of separation logic. 

For example, at B, insert is about to return the list that y points to (at 
location &y). At this point the context is given by the A and E\ from eqs. <[9|) 
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and dl). Art checks that the context satisfies the output type of insert i.e. 
that &y is the root of a valid list whose length equals one greater than (the 
snapshot of) the input x. It uses subtyping and T-fold to obtain at C: 

r 2 = Ji, len ( 3 / 1 ) = 1 + len(null) S 2 = So * &y >-+ y : :list[A] 

Using lemma [0 and lemma [1 we have: [Pi, S\ ]| => [P 2 , S 2 ] In particular, note 
that j 1 names the snapshot value corresponding to the (single-celled) list referred 
to by y, and the measure instantiation due to T-fold states that the length of 
the snapshot is 1 greater than the length of the tail null. The implication follows 
from the definitions of the length measure, the snapshot predicate and the type 
predicate. We then use the implication in an instance of the consequence rule. 

Soundness of Art follows from the following: (1) data type definitions cor¬ 
respond to an inductively defined set of pure snapshot values; (2) heap binders 
correspond to snapshot values; (3) no data structure is modified without first 
unfolding it, ensuring that each “snapshot” (or “version”) receives a fresh name. 

D.3 Assertion language 

Values in Imp are records, integers (which are also used as addresses), the con¬ 
stant null, or products of integers and records. We assume an intuitionistic 
interpretation of assertions (and thus p * true p). 

Value = Z u O u {null} 

O = Records 

Z = Integers (and addresses) 

§ = Z x O 

Expressions E :: = 

| (/: Ej record constant 
| f(E) UIF application 

Assertions P :: = 

| emp empty heap 
| E >—> E singleton heap 
| P * P separating conjunction 

With the following axiom: 

{y = <.../ :e...» =► (P <s> [field(y, f)/e]P) (12) 


D.4 Imp Proof Rules 


In addition to the standard frame rule and consequence rule, we assume the 
following axioms: 

Proof Rules 


F h {P} s {Q} 


Concretization 


2 f. FV(e) x, 2 distinct 
I- {x 1—> e] concr(:r, z) {x >—> e a 2 = e} 
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Unfolding 

b {3a;. P} unfold(t,a;) {P} 

Folding 

x does not appear free in P 
b {3a;. P } fold(^, x) {P} 

Padding 

t, x distinct 

b {emp} pad(£, x) {emp a l = null a x = null} 

Assignment 

x i FV(e) 

b {emp} x = e {x = e) 

Conditional 

F b {B a P} ai {Q} P b { 'P a P} s 2 {Q} 

P b {P} if P then s-j else S 2 {Q} 

Allocation 

x,z £ FV(e) 

b {emp} x = z alloc {/ ; e} {a; = t a £ b null a x *-►t a 2 = </:e>} 

Access 

a, v distinct vars 

b{a>-* </:e>} u = a.fi {o </: e) a v = e*} 

Mutation 

t £ FV(v) 

b{aw(.../,:-...)} a.fi = z v {a z a z = (... fi'.v ...)} 

Sequence 

P b {P} s {P} P b {P} s' {Q} 

Pb{P} s;s'{Q} 

Procedure Call 

g(a;i... x m ) = s; return a: 0 
{P} g(xi ... Xm) {Q}, P b {P} s; return x a {Q} 

P b {P} a; = g(xi ... x m ) {x = x a a Q} 

Return 

b {[e/a; 0 ]P} return e {P} 

D.5 Definitions 

Definition 1 (Base type translation). 

[a;:mt] = int(x) 

[a; mull] = (a; = null) 

[a;:(f)| = ((x = £) a (x b null)) 

jxP (4j = ([s:< l)I v [a;mull ] 

[ x: (ft : Ti) ] = (x = </*: field{ x, /*)> 
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Definition 2 (Local type binding translation). 

{x:{v.b\p}} = [x/v]p a lx:bj 

jx-.{v: C[T] | p}] = jx/z/jp _ 

\x:{v:{fi:Ti) | p}] = jx/z/jp a [ a; :: T))J a A [ field{x, ff ): A ] 

fiTiET 

Definition 3 (Heap type binding translation). 

>— a:: |z^:C'[r] | p}] = ((f # null) => ([x: {z/: C[T] | p}]]) * c(T,£,x)) 

a ((£ = null) =^> (x = null)) 

{(■*-* x:{v.{fi\Ti) | p}] = ((£ # null) => {\x:{v:t | p}] * t *-* x) 
a ((£ = null) =^> (x = null)) 


Definition 4 (Free Variables of r,£). 


FV{0) = 0 

FV(xT) = {£} v FV{r) 

FV(x:(€)\ T) = {£}vFV{r) 


FV(emp) = 0 

FV{£ >-> x: T * S) = {£, x} u Fl/(i7) 


Definition 5 (Pure Value Types). In order to show measure well formed- 
ness, we extend the language of types with products (T x T') and unions with 
null (T + null/ ; and define: 

SnapType : Type x Heap —> Type 


SnapType((f); ZJ) = 


,(£) x SnapType(T, 17) £<-+x:T e £ 

[(£) £ f Dom(£) 

SnapType(?(A) £) = SnapType«f!), S) + SnapType(null, S) 
SnapType(T, E) =T 


Definition 6 (Pure Values from Type Definitions). For each type T we 
denote the pure values associated with that type as T *, which we define induc¬ 
tively: 

_ e £ Z _ e e Value 

null e null* e £ int* e £ a* 

e £ Z _ e £ null* e e (0 

e £ (£)* e £ ?<£>* e £ ?(£)* 

e = (fi-Tf) esTj* ei £ Ti* e 2 £ T 2 * eeT0veeT 2 * 

(fi ■ e-i) £ (fi : A>* (ei,e 2 ) £ (Ti x T 2 )* e £ (T) + T 2 )* 

C[a] = 3! r. x:T 

e £ (SnapType([T' Q /a]T, \T a /a\E) + null)* 
e £ C[T a f "" 
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Definition 7 (Constraints from Pure Values). We consider elements of C* 
as “snapshots” of some heap. We “restore” these snapshots by mapping them to 
assertions with the functions 

Snapshot: Z x Value —> Prop 

Walk : Value — > Value x P(Z x Value) 

Snapshot(£,x) = ((£ / null ) => {£ >—> e®^^) € h t' e')) 

where (e, h) = Walk(x) 
and where Walk is defined as follows: 

Walk((fTe}) = «7T^ 7 >, U h) where ( e',h ) = Walk(e) 

Walk((ei,e 2 )) = (ei, {(ei, e 3 )} u h) where [e^,h) = Walk(e 2 ) 

Walk(e) = (e, 0) 

Definition 8 (Assertions from Type Definitions). Given the definition 
C\a\ = 3! E. x:T, define the assertion 

c(T a ,£,x) = (3x c , FV{E). (f i —> x c a Jx c : [T q /o]TJ) * [[ [T Q ,/a]Z'J a Snapshoot,x) 

Definition 9 (Interpretation of Measures). Let m(x:C[a ]) = e and s be a 

mapping from variables to values. Define [m(a;)] eX p = [[ejexp where 

[vjexp(s) = V 
Ix.fjexp(s) = S(x).f 
If(e)]ex P (s) = /([e]ex P (s)) 

[ei ©e 2 ] exp(^) |^1 1 exp (s)©[e 2 J exp(^) 

© G { + , 


{ife thene i else e 2 Jexp(s) 


| [ei]ex P (s) [e]ex P (s) = true 
[Ie 2 ]exp(s) otherwise 


Definition 10 (Interpretation of type contexts/worlds). 

l r i = /\e /\{x:Tj /\{typet = T} 


eeT xTeT 


type---er 


m= * It- 

i^xTeS 

= ifm a is] 


Definition 11 (Interpretation of procedure declarations). Assume that 
f(x) = s. Given S = W. Va. ( x:T)/Ei => 3!f 0 . x 0 '.T 0 /E 0 , 

Pre(S) = [xlT] a Ir.,] 

Post(S) = [xoiTo] A [[A7o ] 

Body if) = s 

and the variables appearing in Post(S) and not Pre(S) are considered to be 
modified by f. 
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Definition 12 (Interpretation of procedure contexts). 

!/:£;*] = {Pre(S)} Body(f) {Post(S)}; [*] 

D.6 Type Soundness 

We assume the following: 

1. The set of program variables (x,y, etc.) is disjoint from the set of symbols 
used to denote locations (£, £', etc.). 

2. All programs are in single static assignment form. The only variables which 
have more than one static assignment are “phi” variables which are assigned 
once in each branch of an “if” statement. 

Lemma 3. If for every x:T e T, T b T, then the only symbols that appear 
in JT] are variables (x,y), arithmetic and equality symbols and uninterpreted 
functions, and no variable appears bound twice. 

Proof. By induction on the type well-formedness judgement. 

Corollary 2. The location £ only appears m [T] if there exists x:T e f and 
T = {»:(£) \p} orT = {»:?(£} \p}. 

Lemma 4. If T \- £ , then for each £ >—> x:T e £: 

1. No binding x:T' appears in T. 

2. [ £ ] contains exactly one sub-assertion of the form £ * x. 

Pi'oof. By definition of [A] and induction on the well-formedness judgement. 

Lemma 5. If P,£ |— S, then the formal arguments or free variables of the 
output world of S do not appear free in T or £. 

Proof. By the assumptions of WF-FUN 

Corollary 3. The location £ only appears in [A] if there exists £' >—► x : T e £ 
and £' = £ or T = {v\(C) | p} or T = { v.Nff) \ p). 

Lemma 6. If \~m m(x:(7[a]) = e, and v e C*{A), then [ [n/x]e]exp e Values. 
Proof. By induction on the T \~m e : T judgement. 

Lemma 7. [Subtyping] 

• If FhTi<T 2 then [T] => [Ti]| => [T 2 ] 

• If r h£i<£ 2 then [F] => [Tr] => [r 2 ] 

Proof. By induction on the subtyping derivation. 

Case r \- {v:t \ p} < {v : r | p'} 

By assumption. 
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Pc 


Ca.se r^{v.C[T]\ Vc }<{v:C[T]\p' c } 

By assumption, 

l r ] a p c 

and 

I-H a [i/:T] =4. \v:T'\ 

for each T, T'. By hypothesis and the definiti on of f • | , and by the form 
of each T, each p only occurs positively in c({z v.t | p},t,x). Destructing 
T as {v:t \ p} and T' as {v:t \ p'}: 

\w.{v.CfT\ \p c }j =pc a 3b c(T,£,u) 

=> p'c a 3b c(T', i , v) 

oiv.{v.c[T]\p / c n 


Case r b | p} < { w.(f:T '> | p'} 

Unfolding the definition of [[•]], 


\ p] ] = p a = </:field(/, v)) 


a [field 

By hypothesis, 

for each T, T', and applying eq. 0 gives us 

[r]^[fieldK/):T]^[field(u,/):T'] 

Now, 

[i/:TiI =p a </:field(b/)> a /\[field(i/,/) :T] 

f-T 

so, combined with the assumption that [U]| => p => p', 

[T] =^p a </:field(i/,/)> a /\[field(i/,/):T'] 

fT' 


which is equivalent to {i':(/:T') | p'} 


Case U b \ p} < {n:(l) | p'} 

By assumption, 

[T] =>p=> (p' a / null) 

By definition, 

[ v : {i/: ?<7) | p} ] = p/\{y = l/\v^ null) v (n = null) 
and thus, combined with the assumption, 

[-T]=>p=>(p'Ai/ = fA^=b null) 

which implies 

\v:{v.(l') | p ’}\| =p'/\v = Iav¥= null 
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Case r |- {v:(f) \ p} < {v:l(f) | p'} 

By assumption, 

[ T ] =£■ p => (p 1 a null a v = l) 

and thus 

j[ C ] => p => (p r a (( 1 / / null a v = l) v v = null)) 
which is equivalent to \v:{v.7(Jf) | p'}]. 


Case r h {^:null | p} < \ p'} 

By assumption, 


irj^p^ 


(p 1 A V 


null) 


and thus 


[[ C ] => p => (p r a (( v i=- null a v = l) v v = null)) 
which is equivalent to |V:{za?(Z) | p'}]. 


Case r \- emp < emp 

The heaps are equivalent and their domains are empty, so the conclusion is 
trivially true. 


Case r \- £ * £ >—* x\T <£'*£>—> x:T' 

By the inductive hypothesis, 

[71 => [ 17 ] =>[£'] 

and by assumption and the definition of [[ • ], 


hence, 
and thus, 


in*>ie~x:T]*[Z]^ie~x:rilZ'l 
[r] =*> \t^x:T*£\ => \£^x-.T' *£'} 


□ 


As a consequence of our interpretation of typing contexts, the following lennna 
immediately follows: 

Lemma 8. Assume that d>, F, and £ are (respectively) well formed global, local, 
and heap contexts. We may then write the denotation of these typing contexts in 
the following way: 

lr,£\ = G*H 

where the following hold: 

1. G is pure. 
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2. G is a conjunction of the assertions 

G x = lx:Tj 

for each x:T e T. G may thus be written • • • a G x a • • • for each such binding 

in r. 

3. H is a conjunction (via *) of the assertions 

He. = [f = nil v \t *—> a;: T ]) 

for each I >—> x: T e E. G may thus be written ■ ■ ■ Hi ■ ■ ■ for each such binding 
in E. 

Proof. Follows immediately from the definition of [ — ]. 

Lemma 9. 

If r,EPe:T 
Then lr,Ej=G*H 
such that 

1. G is pure. 

& G^le:T 1 

Proof. By induction on the expression typing judgment. In particular, we make 
use of the fact that the typing and subtyping rules for pure expressions only 
depend on T. Subsumption requires application of lemma 0. 

Lemma 10. Suppose that T, E \- x : (Ij and that r \- E = Eq * £ <-* y :T. It 
then follows that [F, FJ = G * H * Hi where G is pure and: 

(i) G => (x = t a x =£ null) 

(ii) H = H' * Hi* H" such that 

G * Hi => \x >->■ y-Tj 
and furthermore, if T is a record type, 

G*\x'-*y.T\*Hi^>X'-^y 

equivalently: 

G*{x y.T\ * => x^ < fi:field(y,fi )) 

Proof. Follows from lemma 0 and the definition of [[ — ]. 

Lemma 11. [Folding] If F (- x:T\/E\ \> x '.T-ifE^ then 
[.T] =^> x:T\ * E\ \ => 3FV(E2). [ 1? : F2 * F2 ] a 3 y. Snapshot{I, y) 

Proof. By induction on the judgement derivation. 

Case F-base 

By the subtyping hypothesis, 

[r]Al£~x:T a }^[e~x:T 2 } 
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And thus, by letting every other £ e Dom (£ 2 ) = null, 

3FV(A 2 ). ie^x:T 2 *E 2 j. 

Since Tf contains no pointers, and since we are assuming the satisfiability of 
\x:Ti ], we can construct y from the base type of T\ and its refinement. 


Case F-ref 

By the subtyping hypothesis, where T\ = {n:(£') \ p}, 

And by the inductive hypothesis, 

[ rj => [f ^x:T* E[j => 3F V(A'). {£' ~ x:T' * S' 2 ] a 3s. Snapshot^', e) 
Combining the two gives us 

3FV(A 2 ). l£~y:T 2 *E 2 }. 

We construct y = {£', s ) so that y e (£') to yield 

Snapshot(f, y) 


Case F-?ref 
B y hypothesis, 

(( 2 : A null) a [F, £ > x :T * £[ ]) => 

(3FV(A'). \£^x-.T' *F'J a V- Snapshot^, y')) 
(( 2 ; = null) a [[ r, £ >—> 2; : T * £[ ]) =^> 

(3FV(A'). \£^x-.T' *F'J a 3y'. Snapshot^, y’)) 
In the first case, (2: A null) we let 

y = 


In the second case, 


y = null. 


We combine both hypotheses and y constructions to conclude: 

3FV(A 2 ). 1£^x:T 2 *S 2 }. 
and, by definition, Snapshot^, y), 


Case F-HEAP By hypothesis, 

\r,£ x:T * A 1 ! J) => 

(3FV(A 2 ). \£ >-> x:T * A 2 J a 32 :i. Snapshot^, 2:*)) 

for each field( 2 ;, /;) in T\. If we substitute field( 2 :, /;) for x in each conclusion, 
we conclude 

{£ ^x:T 2 * A 2 J 


and we construct y = (fi'.Xi). 
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□ 


Lemma 12. Given the definition 

C[a] = 31 E.x:T, 
and the set of corresponding pure values, C*{A): 

Snapshot(£,Xf) a \£ >—► x:T *17] =► Xf £ C*(A) 

Proof. By contrapositive. Assume Xf f C{A)*. Then 

xf i Pur e c {A,C*,T)S. 

The proof is by induction on the derivation of Xf f Pur ec{A,C* ,T). The base 
case starts with the root of Snapshot^, xj) 

Snapshot^, Xf) = I >—> e * • • • 

If x v f Pur ec(A,C*,T)E then either e is not a record value, trivially showing 
'-* x:T * A]], or x v contains some field / with value e/ such that. 

(f) f-.TfeT- 

(ii) and e/ f Purec(A, C*,Tf)E 

Assuminge/ A (t",e'),ife/ f Purec(A, C*, Tf)E, then the assertion in Snapshot^, Xf), 
i i-> {.../: ej .. .), must not satisfy the corresponding [ 1 >—> x: T ] (by the defini¬ 
tion of Purec(A C*, T)E. If e/ = (£', e!) for some f, e!, then e' f Pur ec(A,C* ,Tf)E 
However, by the same reasoning as above, Snapshot^', e') must not be equisat- 
isfiable with [ (. ^ x:T * A ] 

Theorem 2. [Statement Typing] If 4>,r,E\-s :: r’/E’ then [[<£] b 

{[T,r]} s {[r,r']} 

Proof. By induction on the typing derivation of s. 

Case x = e: 

By assumption, x does not appear in r. Since e is well-typed, x f FV(e). By 
the frame rule, since x f T and x f E, we derive the following rule: 


P {{r,EJ} X = e {lr,Ej* X = e} 
We then perform the deduction by the definition of [•:•]]: 
{ lr,E] A(x = e)} 

{ a \x:{v:t \v = e}\) 

{ \x:{v:t | v = e}-,r,Ej } 


Case s; s' 

By hypothesis, 


<Pp{ir,E}} Sl 
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<Pb{[r',r']} S 2 {ir",r"]} 

By straightforward application of the sequence rule, we immediately conclude 

£b {ir,Ej} Sl ;s 2 {ir",E"]} 


Case if e then Si else s 2 : 

By hypothesis: 

and 

<?> b {-e A ir,s}} S 2 {[r 2 ; r, r 2 * r' ]} 

For each Xi , by lemma @ 

ir^rj^lxi-.T'j and 
and by lemma @ 

[A;r] =>[£!] =>[£'] and [A; T] =* [ £ 2 ] =* [ S’ ] 
Combining these facts allows us to conclude, 

=> and [A; T, E 2 ] => [^TA; A S'} 

and thus, by consequence, 

^ b {e a [r,r]} Sl {[iTT Y i; r,s'}} 

and 

^ b {-e a [r,r]} s 2 {ix~Tr z -r,s'}} 

hence, by the conditional rule, 

<P b {[-T, ^]} if e then si else s 2 {fxi :Tj; A S' ]} 


Case concr (x,z): 

Letting \ = G * H by lemma 0, by assumption 

{G*H} 

By hypothesis and lemma M 

{G*H*(x = £a£=£ null) * \ £ ^ y:T y \ } 

By consequence, assuming without loss of generality that T y is a record type, 
substitution on the rule for concr, and applying the frame rule, 

{G*H*(x = £ a £ i=- null) * x >—* y *\y-T v \ } 
concr(.t, z) 

{G*H*(x = £ a £ ^ null) * x >-* y *\y-T y \ a z = y }, 
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since z is a fresh variable. By definition of J — J and T y >, since 2 does not 
appear free in G , H or T y , 

{ ly:T v -,rj~z:T z *Z'j } 


Case pad(£, x) 

Beginning with the proof rule for pad(£, a;), 

I— {emp} pad(£,a;) {emp a £ = null a x = null} 

By hypothesis, neither £ nor x appear in T or S, and thus do not appear in 
fr, 17], so we can apply the frame rule: 

|— {[T, if J} pad(£, x ) {[/) £ J * (£ = null a x = null)} 

By consequence, 

h{ir,z}}p a d(i,x){ir,z}*ie~x-.T}} 

And thus, 


h{[r,rj}pad(£,a;) {[r, £ * £ - x:Tj} 


Case unf old(£, z) 

Letting [C, A] = G*iL*[£>—► x: C[T] ] by lemma @ and by assumption, 

{ G * H * (((£ / null) c(T, £, x)) a ((£ = null) => (x = null))) } 
First, assume £ = null. Then, 

| G * H * (£ = null a x = null) } 

And by lemma 0, 

{ G * H * (x = null) a /\l m(null) ] exp = e m } 

m 

Quantifying over x allows us to complete the proof via consequence and the 
frame rule: 

{ 1 ^ 1 } 

{ 3FV(...). G * H * (£ = null a x = null) a AI m (null) J exp = e m } 

m 

unf old(£, y ■ y ) 

{ G * H * (£ = nulla: = null) a /\j m (null) ] eX p = e m } 

m 

{lAl m (y)W = em;r,r']} 

m 

Next, we assume £ A null. By definition, 

{ G * H * 3x c . 3FV(A7 C ). \t >-* x c \T c * a Snapshot(£, x) } 
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By hypothesis, x c and the free variables of [i7 c ] have been a-renamed and 
do not appear in [TJ or [17]]. By the unfold axiom and the frame rule, 

{ G * H * 3x c . 3FV(£ C ). ^ x c :\T/a]T c * \T/a]S c j a Snapshot^, a;) } 

unfold(£, x c ■ Dom(£ c ) ■ Binders(S c )) 

{ G * H * f£ >-> x c :[T/a]T c * [T/a]I7 c ] a Snapshot(£, a;) } 

where x e C*. Therefore, by lemma 0, each well-formed measure on C[a], 
m, is defined on x and we strengthen: 

{G*H *\[ x c :[T/a]T c * [T/a]£ c j a Snapshot^, x) a m(:r) ] exp = e m } 

m 

Which is, by definition 

{ [A^Wlexp = e "b r J a } 


Case x = z alloc {/:e/} 

By assumption, x does not appear bound in r and £ does not appear in 
[-T, A]. Applying the frame rule to the rule for alloc gives us the precon¬ 
dition 

{ ir,sj } 

and the postcondition 

{ [-T, £\ * x = £ /\ £ ^ null Aa;>—>ZAz = (/:e)} 

Rearranging and by consequence: 

{ fr, * x = £ a £ =£ null a (£ # null =^> £ <— > z a z = (/: e)) } 

By the typing hypotheses and lemma 0, 

[r]=>|[e:I>] 


{ [T, A] * x = £ a £ # null a [£ null £ <— > z a z = (/:e) a [e:Ty ]) } 

so eq. (1121 1 and the definition of [ • ] imply, 

{ ir,£*£~z:Tj } 


Case y = x.fi 

By hypothesis, lemma H and lemma 1771. we let 

ir,£j = G*H*l£»z:(... f t :field(z, ff )...)] 
and by consequence, 

{ G * H * [z: (j\Ti) 1 * a; ~ <... /pfieldfz,/,)...) } 

By the frame rule: 

{ G *H * [[z:<7 TtT>] **>-<... /< :field(z,/i)...) } 
y = x.fi 

{ G*H * [z:</:Tj>] *x >-» <... /* :field(z, /*)...) a (y = field(z, /»)) } 
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Unfolding the definition of | • ] and by consequence (using the equality y = 

field 

{ G * H * lz: </7Ti>] * x >->■(... fi : field (z, ff)...) a [T, :y ] } 

And hence, by definition and consequence (to weaken the mapping of x and 
applying the equality x = £), 

{ ly:Ti-r,Sj } 


Case x.fi =~ e: 

Starting from { JU, A] }, by lemmas @ andflil we deduce by consequence, 
{(G*{x = £ a£^ null) *H * \y :(fj : {v.Tj | Pj}>J * x </, :field(y,/,))) } 
Thus, by the frame rule, 

{{G*(x =£ a £ A null) * H * H y: </y : : Ty | p^})]] * x -> (fj :field(y, fj))) } 

x.fi = z e 

{ (G * (x = l a £ =£ null ) * H *\y.(fj-.{v:Tj | Pj}>] * x >-> 2 a 2 = (... /j :e ...)) } 
By consequence and lemma 

{ (G* [e:{v:r \ p} ] * (x = £ a £ # null) * H 

*ly-{fo-{ v - T o \ Pj})1 * X z A z = (... fi-.e...)) } 

Unfolding the definition of J-J, this expands to 

{ (G* [e:{u:r \ p} ] * (a; = £ a £ ± null) * H 

* V = (fj- fie ld (y, fj)) a /\[ field (y, fj):Tj ] 
fPi 


* I y-(fj'-{v- T j I Pi}>] *x >-»• z AZ 


By eq. OJ), 


<••■/» :e ...» } 


{ {G * \ e\ {v :t \ p} \ * (x = £ a £ ^ null) * H 

*V = (fj : f ield(j/, fj)) a /\[ field (p, fj) :Tj ] 
ffl'i 

* ly-(fj-W-Xj |Pj}>] *x^> z 
a z = </ 0 :field(y,/ 0 )..field(z, fi )...) 
a (field (z,fi) = e) } 

By definition of [[•]], 

{ (G * \ e\ {v \ t \ p} \ * (x = £ a £ ^ null) * H 

*V = (/j :field(p, fj)) a /\[field(y, fj):Tj ] 
ffl'i 


* \ y-(fj '■ { u:T j I Pj})i * [£^ z:T r j } 
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and thus, by definition, 


x.fi = e 

{ [r,£~z:T r *E] } 


Case f old(Z, z) 

Given C\a\ = 3! Z. x:T, 

c(T a , £, y) = (3a;, FV(I7). \i*-* x\ \T a /a\T * [T a /a] A J a Snapshot^, y) 

By lemma [ill applied to the type judgement folding assumption we deduce 
3FV(A C ). \l i—» x:6T c * 9E C J a By. Snapshot^, y) where 8 = [T/a] 
and, by the definition of c(T,£,x): 

c (T,£,y) 

Applied to the rule for fold (£,y), since by assumption y is a fresh variable, 
I- {3 y. c(T,£,y)} iold(£,y) {c(T,£,y)} 

By lemma 12, x e C[T]*, so by lemma@, each well-formed measure on C[a], 


m, is defined on y. By the form of T c and the definition of Snapshot, for any 
field of x field (y, f ) = field (x, f ) and we thus strengthen the postcondition; 

{ c{T,£,y) a /\m (y) = e m }. 


Applying the frame rule and consequence with the definition of T y and 
lemma [ t] applied to A', 

$\-{[r,t~x:T x *E x *Z]}fold(e,y) {\r,£ hh. y:T y * J7']} 


Case x r = /( x) 

Assuming f:S and 

S = W. Va. (x7T)/Ei * E'i =► 3!C x 0 :T 0 /Z 0 
let P = Pre(S) and Q = Post(S). We apply the substitution 8 = \ej/xj\ to 
obtain: 

8P = \^8T J } a 10E Z } 

8Q = lx 0 :8T 0 }AldE 0 j 

By lemmas @ and 

1*1 => I ej-.OTj} 

[-H =► [^m] => {OEij 

and thus 

ir ] =► lE u *Zmi => [A] a8P*Z u 

Which gives us, by consequence, and framing of r and E u , and unfolding 
the definition of Q, 

{lPE m *E u }}x = f(ej) (I r,Z u *8Z 0 \} 
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□ 


Theorem 3. [Procedure Typing] 

If then [<2>] b {Pre(S)} Body(f) {Post(S)}. 

Proof. Let 

P = Pre(S) = IxTT ] a [ I7j ] 

Q = Post(S) = lx 0 :T 0 jAlS 0 j 

By inversion on the judgement, we must have typed a statement s' = return e 
for some expression, or a sequence of statements ending in a return. By the 
statement typing theorem, 

<Pb{Pre(S)} S {[T s ,r s ]} 

Applying lemma|| and lemma. 0 to the hypotheses of the return typing rule, we 
determine 

lr s ,Zsl => [e/x 0 }lx 0 :T 0 i 

ir s ,E a j^[e/x 0 ]lS 0 l 

and thus 

b {[P s , A’ s ]|} return e {Post(S)}. 

By the sequence rule, 

b {Pre(S)} s; return e {Post (£)}. 

□ 

Corollary 4. [Soundness] If <I> , 0, emp b s :: P /E, then [<£] b {true} s {true} 

E Heap Annotation Inference 

Up until this point, our presentation has assumed that the annotations concr, 
unfold, and fold have already been inserted into the source file. To alleviate 
this burden, Art automatically inserts these annotations at critical locations 
in the input program. To be sure, the soundness of the type system does not 
depend on any particular algorithm for inferring these locations. In fact, while 
the algorithm we will present was sufficient for the benchmarks we used to test 
Art, it would be entirely feasible to swap our algorithm for another. In this 
section, we will describe the simple source elaboration that preceeds refinement 
type checking and inference. 

Annotation inference. To formalize our method of inferring annotation loca¬ 
tions, we define a function J- with type: 

T : Statement x S —* Statement x V{U) 

S = Type Bindings x Heap x Function x U 
U = Location x Type Constructor 
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Thus, F(s, (r, E, f,M)) transforms the statement s yielding a new (possibly com¬ 
pound, i. e. comprising several sequenced statements) statement and a new set of 
unfolded locations. The input to J- is s, the statement to be transformed; F, con¬ 
taining physical type information for local variables; £, containing physical heap 
type information; /, the physical specification of the function containing s; and 
U, a set of (£, C) pairs that denote unfolded locations and the type constructor 
that was unfolded. 

Because this step preceeds refinement type checking, the only type informa¬ 
tion that is available is base type information - i.e. all types are of the form 
{v:t | true}. Definitions for T on the statements that may possibly generate 
annotations are given in Fig. l2ll with some helper functions given in Fig. [22. 


Function Declarations. T transforms programs function by function. Thus it 
simply calls T recursively on the function body, querying the type system to 
determine F and E with Env(/) and Heapln(/). 

Field Access and Mutation. On a field read or write, Art computes the 
set of locations that must be unfolded, using the UnfoldList helper. UnfoldList 
computes this list by (1) consulting r and heap to determine if x points to a 
location that is folded up; and (2) subtracting from this list all locations that 
are already unfolded . Art inserts unfold calls for these locations before the 
Held access. 

Art also optimistically inserts a concr before a field access. The concr will 
type check exactly when the field access type checks. 


Function Return. At function returns, Art must take care to ensure that £ 
agrees with the current function’s specified heap with respect to which locations 
folded. If a location in the function’s schema is unfolded, it must first be folded 
up. At a return statement in a function, /, Art computes these locations by 
comparing the current heap, E with f’s specified heap. Given a “current” heap 
E and a “target” heap £', Fold List computes the set of locations in E that must 
be folded up. These locations may depend on each other, so Fold List orders these 
fold calls using the FoldOrder function. 


Function Calls. With respect to folds, function calls behave exactly like func¬ 
tion returns. 


Example. Revisiting abslist, consider the following: 


var 11 = { data:0, next: null }; 
var 12 = { data:l, next:11 }; 
absList(12); 

Fold List determines that the locations (and their associated types) that must be 
folded up before calling abslist are (&12, List [number]) and (fell, List [number]). 
However, &12 depends on fell. FoldOrder realizes this dependency with the cor¬ 
rect ordering fold(&ll); fold(&12);. The code is annotated with fold and 
concr calls are as follows: 


var 11 = { data:0, next: null }; 
var 12 = { data:l, next:11 }; 
//: fold(Stll); 
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//: fold(&12); 
absList(12); 

If Statements. To annotate if statements, Art calls T on the statements 
in the “then” and “else” branches. To determine which statements must be 
folded, T calculates three sets. L\ and L 2 are the sets of unfolded locations that 
were previously folded before the if statement. Additionally, T queries the type 
checker to get heaps £\ and £ 2 that are returned from type checking Si and 
s 2 , respectively. These heaps are used to determine L a i ias , by calling Alias. This 
procedure determines if a location £ would cause any references to become aliased 
(and thus eventually fail to type check). Using the same ordering as in function 
returns and function calls, Art calls FoldOrder to determine the sequence of 
folds that need to occur in both the “then” and “else” branches. 

Example. In the following, suppose x is a pointer to a list. The code 

var d = x.data; 
if (d > 0) { 

x.next = { data: 1, next: null }; 

} else { 

x.next = { data: -1, next: null }; 

} 

would thus be annotated 

//: unfold(&x) 
var d = x.data; 
if (d > 0) { 

x.next = { data: 1, next: null }; 

//: fold(ftx) 

} else { 

x.next = { data: -1, next: null }; 

//: fold(ftx) 

} 

because the next fields of x. next at the end of either branch point to different 
locations. Folding ensures a consistent view of the heap after the control flow 
join. 

Padding Whenever a heap subtyping occurs, it is possible that the sub-heap has 
fewer locations than the super-heap. However, the heap subtyping judgements 
requires the sub-heap and super-heap to have equivalent domains. We insert pad 
statements at these locations when the physical type checker determines that the 
sub-heap’s domain is too small. 
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^(function f(x) {s}, 5) = (function f(x) {s'}, 0) 

where (s', -) = J°(s, (Env(/), Heapln(/), /, 0)) 

T(y = x.fi, (. r,E,f,U )) = (concr(*); m; y = x.fi,U') 
where (u,U') = UnfoldList(x,F, E,U) 

F(x.fi = e, (r,E,f,U)) = (concr (x);u;x.fi = e; concr (x),U') 
where ( u,U') = UnfolcLList(x,r,E,U) 

T(x = g(e), (r, E,f,U)) = (w;p;* = g(e),U') 

where p = PadLocs(<C, HeapOut(g)) 

(w,U') = FoldList(E, HeapOut(g),U) 

_F(return e, (F, E, f,U)) = (u>; p; return e, 0) 

where p = PadLocs(X', HeapOut(f)) 

(w,U’) = FoldList(E, HeapOut(f),U) 

F(lf e then si else S 2 , (-T, E, f,U) as <S) = (if e then si; wi\ pi else S 2 \ W 2 \P 2 ,lA\L a u aa ) 

where p\ = PadLocs(X'i, E 2 ) 

P2 = PadLocs(X , 2, 

(s’i,Ui) = F(s\,S) 

(S2M2) = F(S2,S) 

(E\,E 2 ) = (FleapAfter(si), HeapAfter(s 2 )) 

Laiias = {(l, C ) I Alias(£, E l7 E 2 ) a (<, C) e U} 

(Li,L 2 ) = (U!\U,U 2 \U) 

wi = FoldOrder({fold(£) | ( £,C ) e Li uL oii „},r) 
w 2 = FoldOrder({f old(£) | (00) e L 2 u L a i ias }, E) 


Fig. 21: Statement annotation insertion 
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UnfoldList(x, F, E , U ) = (U, L u 77) 

where U = {unfold(7) | (7, C) e I/\77} 

L = {(7,C) | 7 e TypeLocs(r,*) a (£^y.C[T]) e E} 


FoldList(E,E',U ) = ( W,LnU ) 

w/iere VF = FoldOrder({fold(7) | (7, C) e Z/\L},r) 
(L,L r ) = (M7oMndZ/Ocs(Z’), lFotm<iLocs(X' , )) 


Alias(f, i7i, £ 2 ) = 7 h-> .. f:ri .. .) e E\ a £ >—> *2 • • /:t 2 ...) e E 2 

a |tocs(n) u Iocs(t2)\ > 1 


TypeLocs(T, a;) = {Iocs(t) \ F \- x : t} 


WoundLocs(E) = {(7,C) \ £^ x:C[-]e E} 

PadLocs(£, E') — {pad(7) mod £ e Dom{E')\Dom{E)} 


Fig. 22: Annotation insertion helper functions 




